home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1997 January: Mac OS SDK / Dev.CD Jan 97 SDK2.toast / Development Kits (Disc 2) / OpenDoc Development Framework / ODF-Interest Archive / March 96 / Re Initializing an Extension.5 < prev    next >
Encoding:
Internet Message Format  |  1996-12-03  |  3.0 KB  |  [TEXT/ttxt]
  1. Subject:     Re: Initializing an Extension
  2. Sent:        3/9/96 1:11 AM
  3. Received:    3/11/96 8:27 AM
  4. From:        Jim Lloyd, jim@melongem.com
  5. Reply-To:    ODF-Interest@CILabs.ORG
  6. To:          OpenDoc Development Framework Discussion List, ODF-Interest@CILabs.
  7.  
  8. At 11:17 PM 3/8/96, Bernhard S. Wieser wrote:
  9. >Why would you want to register the part with the
  10. >extension via its init method?  Shouldn't it be the other way around?
  11. >The part registers the extension.  If the part wants to get access to it, it
  12. >calls GetExtensionManager( /* no ev in D11 Damon */ )->AcquireExtension(
  13. >ev, kMyExtName )?
  14. >
  15. >Sort of confused...  Thanks in advance.
  16.  
  17. It is the other way around.  The extension manager is a helper object that
  18. the part uses to manage the extensions that are available.  You register
  19. each extension your part makes available with your part's extension
  20. manager.  Then, when an extension-related method of ODPart is called,
  21. ODPart delegates handling the method to the extension manager.  For
  22. example, when HasExtension is called, the extension manager is queried to
  23. see if an extension of that name has been registered with it, and returns
  24. true if one has.
  25.  
  26. In D11, you register an extension by given the extension manager the
  27. extension name and a factory function that will create an instance of the
  28. extension (in ODF 1 you will also provide some additional attributes that
  29. provide you with a little more control over the lifecycle of the
  30. extension).  The extension manager will call the creation function the
  31. first time the part's AcquireExtension method is called for the extension.
  32.  
  33. >p.s.  "Every SOM call can produce a SOM Exception."  I am worried that
  34. >SOM error checking is not consistently apparent.  Do I have reason to be?
  35.  
  36. There is a macro hack ;) that the SOM compiler makes available.  You can
  37. optionally ask the SOM emitter to insert a SOMCHKEXCEPT macro at the call
  38. site of every SOM method.  The purpose of the macro is to inspect the ev
  39. parameter and take some action on errors.  ODF defines SOMCHKEXCEPT to be
  40. FW_FailOnEvError(ev); (the name FW_FailOnEvError is the ODF1 name, I think
  41. it was a little different in D11).  So, if any SOM method returns an error
  42. code in the ev parameter, an exception is thrown.  The flip side of the
  43. coin is that every SOM entry point must have a try block to catch
  44. exceptions and turn the exception into an ev error.
  45.  
  46. Note that if you define your own SOM classes that you will want to make
  47. sure you turn on the generation of the SOMCHKEXCEPT macro when you generate
  48. the .xh files, otherwise clients of your classes won't get automatic error
  49. detection.  Since just a macro is inserted in the .xh file (for each method
  50. definition), the effect of the macro is left up to the client.  If the
  51. client is an ODF application, they'll be compiling with ODF headers that
  52. define SOMCHKEXCEPT as I described.  If the client is not an ODF
  53. application, they'll need to provide some appropriate definition of
  54. SOMCHKEXCEPT.  In addition, you need to make sure that every SOM method has
  55. a try block that will catch all exceptions and turn them into an ev error.
  56.  
  57. Jim Lloyd
  58. ODF Team
  59.  
  60.